home *** CD-ROM | disk | FTP | other *** search
/ NeXTSTEP Products & Services 1994 Summer / NeXTSTEP Products & Services 1994 Summer.iso / AlembicDemo.app / DiskMaker / Demo.disk / dim / ModemSetupGuide < prev    next >
Text File  |  1993-09-19  |  11KB  |  247 lines
  1. (This manual was written by Mark Adler <me@quest.jpl.nasa.gov>, and its provided as an aid for modem installation)
  2.  
  3. People seem to be having problems getting their modems to work, so here
  4. is how my modem is set up and how I use it for dial-in and dial-out (a
  5. public service message):
  6.  
  7. The modem on my NeXT works just honky-dory for both dial-in and dial-out.
  8. I have an Everex/Abaton EverFax 24/96E.  (The fax part doesn't and can't
  9. work since it does not implement a Class II Fax command set, but that's a
  10. different story ...)
  11.  
  12. First off, if you have it, read the online documentation.  The keyword
  13. "serial" will bring up all the relevant documents in Librarian.  Of
  14. particular interest is the zs(4) man page and 13_Peripherals/_Attaching
  15. Modems.rtf.  If you are still using 1.0 or 1.0a, instead get the Technical
  16. Support Note SerialPortDoc.wn from one of the ftp sites.
  17.  
  18. Second, if you have NeXTStep 2.0, and you want to be able to dial-in to
  19. your machine, you will need to upgrade to 2.1.  There are lots of other
  20. good reasons to go to 2.1, so do it anyway.  Dial-in (and out) works in
  21. 1.0 and 1.0a also, if you're still back there in the dark ages.
  22.  
  23.  
  24. CABLING
  25.  
  26. Given that the pins on the male DIN-8 connector look like this:
  27.  
  28.      6  7  8
  29.     3  4    5
  30.       1  2
  31.  
  32. then my cable, which came with an EMAC (Everex) modem, is wired thusly:
  33.  
  34.    DIN-8   DB-25  signal  means                 direction
  35.      1      20     DTR    data terminal ready   to modem
  36.      2       8     DCD    data carrier detect   from modem
  37.      3       2      TD    transmitted data      to modem
  38.      4       7      SG    signal ground         n/a
  39.      5       3      RD    received data         from modem
  40.      6      NC
  41.      7      NC
  42.      8      NC
  43.     case   case           the metal connector housings and
  44.                           probably the cable shield also
  45.  
  46. The NeXT documentation mentioned above says that pin 8 of the DIN-8
  47. connector should be connected to pin 7 of the DB-25 (signal ground) along
  48. with pin 4.  Apparently this is not necessary.  Pin 8 is labeled RXD+
  49. implying that it's a return line for pin 5 (RXD-).  Perhaps connecting
  50. RXD+ to signal ground is necessary at baud rates higher than 9600, but at
  51. 9600, I get no errors in reception.  If you are wiring your own cable,
  52. you should follow the NeXT directions, but if you have a cable like mine,
  53. it'll work.  Pin 8 should *not* be connected ground for serial ports on
  54. 68040 NeXT's (see below).
  55.  
  56. Note that pin 2 on the DIN-8 is labeled CTS (clear to send) by NeXT.
  57. Ignore that.  It should be connected to DCD only.  I bought a $5
  58. Mac-modem cable off a clearance table that had pin 2 on the DIN-8
  59. connected to both DCD (8) and CTS (5) on the DB-25 end!  This cable did
  60. not work.  (If it weren't for the RS-232 standards concerning connecting
  61. two outputs, it might have even damaged my modem.)  If I wanted to use
  62. this cable, I would have broken off pin 5 in the male DB-25 connector.
  63.  
  64. Late press: since this was originally posted, the 68040 NeXT's arrived
  65. and have slightly different serial port connections.  The above cabling
  66. will work fine with the 68040 serial ports, so long as you *don't*
  67. connect pin 8, as the documentation for the 68030 ports suggests.  If you
  68. also want to use hardware flow control, you will need to connect DIN pin
  69. 6 to the DB-25 pin 4 (RTS) and DIN pin 8 to DB-25 pin 5 (CTS).  DIN pin 7
  70. should remain unconnected.  This is the way my new, handmade modem cable
  71. is now wired for my upgraded 040 cube:
  72.  
  73.    DIN-8   DB-25  signal  means                 direction
  74.      1      20     DTR    data terminal ready   to modem
  75.      2       8     DCD    data carrier detect   from modem
  76.      3       2      TD    transmitted data      to modem
  77.      4       7      SG    signal ground         n/a
  78.      5       3      RD    received data         from modem
  79.      6       4     RTS    request to send       to modem
  80.      7      NC
  81.      8       5     CTS    clear to send         from modem
  82.  
  83. In general, any Mac modem cable will work for dial-out, some Mac modem
  84. cables will work for dial-in and dial-out, but no Mac modem cable will
  85. work with hardware flow control.  Of course, you can cannibalize any
  86. Mac modem cable and rewire it, as I did.
  87.  
  88.  
  89. MODEM CONFIGURATION
  90.  
  91. The important control signals are DTR and DCD.  The modem needs to be
  92. set up to respond to DTR and generate DCD in a specified way.  When DTR
  93. is asserted, the modem should allow auto-answer and respond to commands.
  94. When DTR is deasserted, it should not allow the above, and also hang up
  95. the phone if it was off-hook.  The modem should assert DCD if and only if
  96. a carrier is detected.
  97.  
  98. My modem's default behavior is to always assert DCD and to always ignore
  99. DTR.  I suspect that all modems for the Mac and PC world are this way,
  100. since modem control is not needed in most cases.  This default behavior
  101. makes the modem/computer connection a little more robust to cable
  102. variations.  However, it's too limited for dial-in support.
  103.  
  104. You will most likely have to read your modem manual to change this
  105. behavior.  (Perish the thought.)  On my modem, I used the command:
  106.  
  107.      AT &C1 &D2 S0=5 &W0
  108.  
  109. The &C1 makes DCD reflect the carrier status and the &D2 makes the modem
  110. respond as described above to DTR.  The S0=5 tells the modem to answer
  111. the phone after five rings (the default is S0=0, which doesn't answer at
  112. all).  Finally, the &W0 writes the configuration to the non-volatile RAM,
  113. so the modem will always be this way when powered up.  These commands
  114. seem pretty common for modern modems.
  115.  
  116. If you want to use hardware flow control (only available on 68040 NeXT
  117. serial ports), then you will also have to tell the modem to use RTS/CTS
  118. flow control.  You will have to (shudder) read the modem manual.  On my
  119. modem, I used the command:
  120.  
  121.      AT \Q3 \X1 &W0
  122.  
  123. where the \Q3 tells the modem to use bi-directional RTS/CTS flow control,
  124. and the \X1 tells the modem to not use xon/xoff flow control (this allows
  125. xon and xoff to pass through as normal data).  These commands may be more
  126. specific to my modem than the previous commands for DTR and DCD.
  127.  
  128. I recommend using hardware flow control if you have a 68040 NeXT and your
  129. modem supports it.  It is essential for reliable communication at 9600 bps
  130. and above.
  131.  
  132.  
  133. DIAL IN
  134.  
  135. For dialing in, I changed the ttyda line (I use port A for the modem) in
  136. /etc/ttys to:
  137.  
  138. ttyda   "/usr/etc/getty std.9600"       vt100           on
  139.  
  140. where the 9600 is the speed to talk to the modem at, vt100 says to assume
  141. the terminal dialing in is VT-100 compatible (you can leave this as
  142. "dialup" to make no assumption), and the "on" enables dial-ins.  See below
  143. for why I use 9600 bps.
  144.  
  145. If you have a 68040 NeXT and are using hardware flow control, you need to
  146. change the ttyda to ttydfa.  The line in my /etc/ttys actually reads:
  147.  
  148. ttydfa  "/usr/etc/getty std.9600"       vt100           on
  149.  
  150. For any changes to /etc/ttys to take effect, you will need to reboot, or
  151. tell the init process to re-read the ttys file by issuing this command (as
  152. root):
  153.  
  154.      kill -HUP 1
  155.  
  156. Don't mess with the ttya or ttyb lines---they're for permanently
  157. connected terminals and do not allow sharing the port between dial-in's
  158. and dial-out's.  Leave them "off".
  159.  
  160.  
  161. DIAL OUT
  162.  
  163. For dialing out, I use C-Kermit 5A in a Terminal window.  You can use the
  164. command line:
  165.  
  166.      kermit -l /dev/cua -b 9600
  167.  
  168. where the "a" in "cua" selects serial port A, and the 9600 is the bit per
  169. second rate.  I use 9600 since MNP 5, which supports compression, can
  170. sometimes require more than 2400 bps.  It is important to use /dev/cua or
  171. /dev/cub and not any /dev/tty* to allow sharing the port for dial-in and
  172. dial-out.  If you are using hardware flow control, like I do, then the
  173. command is instead:
  174.  
  175.      kermit -l /dev/cufa -b 9600
  176.  
  177. You can get a ready-to-fly compiled kermit 5A for 2.x from cs.orst.edu in
  178. pub/next/binaries as kermit5a.170.bin20.tar.Z.  You can extract the
  179. kermit executable using the command:
  180.  
  181.      zcat kermit5a.170.bin20.tar.Z | tar xvf -
  182.  
  183. and then put the kermit in a suitable directory (as root):
  184.  
  185.      mkdirs /usr/local/bin
  186.      mv kermit /usr/local/bin
  187.  
  188. For kermit to have access to the /dev/cu* ports, it needs special
  189. permissions.  You can grant them (as root) using these commands:
  190.  
  191.      chown uucp /usr/local/bin/kermit
  192.      chmod u+s /usr/local/bin/kermit
  193.  
  194. You should not do this to a pre-5A kermit (e.g. 4E or 4F).  For earlier
  195. versions of C-Kermit, you should instead change the permissions on
  196. /dev/cu* to allow rw access to all.  However, I'd recommend getting a
  197. 5A kermit.
  198.  
  199. You may need to "bootstrap" yourself into kermit by downloading it through
  200. the modem.  Here is a good technique: first, use cu to dial out:
  201.  
  202.      cu 0 -l /dev/cua -s 9600
  203.  
  204. and you will then be able to converse with your modem.  In cu, at the
  205. beginning of a line, you can use the ~? command to get a list of special
  206. tilde commands.  Like how to get out (~.).  (By the way, in my opinion,
  207. the "tip" program is too much of a hassle to use, at least if you are only
  208. trying to get kermit.)  Then dial up the host on which you have ftp'ed
  209. kermit from (I will assume it is a Unix machine).  Use uuencode to print
  210. the binary:
  211.  
  212.      uuencode kermit5a.170.bin20.tar.Z kermit5a.170.bin20.tar.Z
  213.  
  214. and when it is done, copy the contents of the Terminal window to an Edit
  215. window and save it as a file.  (If you are using 1.0 or 1.0a, you will
  216. need to use Shell or Stuart, since Terminal in 1.0 does not scroll.)  If
  217. you have MNP modems at both ends, then you can uudecode the file and
  218. you've got it.  If not, then repeat the process and save it as a different
  219. file.  Use diff to find where the files disagree, and use an editor on the
  220. host to see what those lines are supposed to be and fix them.  However you
  221. do it, check the transfer using the "sum" command on your machine and the
  222. host on the uudecoded (.tar.Z) file.
  223.  
  224.  
  225. SUMMARY
  226.  
  227. 1. Make sure DCD and DTR are wired correctly on your cable, and that
  228.    CTS isn't wired (unless you are using hardware flow control on a
  229.    68040 NeXT--in that case wire RTS and CTS as noted).
  230. 2. Convince the modem to respond to DTR and generate DCD appropriately,
  231.    as well as answer the phone if it rings.  (Also convince the modem
  232.    to use RTS/CTS flow control for a 68040 NeXT, if desired.)  Save the
  233.    setup if you can.
  234. 3. Edit /etc/ttys and put in an "on" to enable dial-in's on the port
  235.    with the modem (ttyda for port A, ttydb for port B).  Change the
  236.    baud rate and terminal type if desired.  (If using hardware flow
  237.    control on a 68040 NeXT, change it to ttydfa or ttydfb.)
  238. 4. Use /dev/cua or /dev/cua with your communication program, NOT
  239.    /dev/ttya, /dev/ttyb, /dev/ttyda, or /dev/ttydb.  (If using hardware
  240.    flow control on a 68040 NeXT, use /dev/cufa or /dev/cufb instead.)
  241. 5. For dialing out, use C-Kermit 5A in a Terminal window (or a Stuart
  242.    window, especially if you're still using 1.0 or 1.0a).  Kermit needs
  243.    to be given permission by root to use the /dev/cu* devices.
  244.  
  245. Good luck.
  246.  
  247.